home *** CD-ROM | disk | FTP | other *** search
/ Hacks & Cracks / Hacks_and_Cracks.iso / manuals / how to crack / htocrk10.txt next >
Text File  |  1996-05-20  |  26KB  |  926 lines

  1.                      HOW TO CRACK, by +ORC, A TUTORIAL
  2.  
  3. ---------------------------------------------------------------------------
  4.  
  5.                            Lesson 1: an approach
  6.  
  7. ---------------------------------------------------------------------------
  8.  
  9.                                [Pooldemo.exe]
  10.  
  11.                    --------------------------------------
  12.  
  13.      The best way to learn cracking (i.e. understanding, broadly
  14.  
  15. individuating, locating exactly and eliminating or suspending or
  16.  
  17. deferring one or more protection schemes inside a software
  18.  
  19. application you do not possess the source code of) is to begin
  20.  
  21. your tampering experiments using OLDER applications which have
  22.  
  23. OLDER protection schemes.
  24.  
  25.      In this way you 'll quickly grasp the base techniques of the
  26.  
  27. trade. Do not forget that the evolution of the protection schemes
  28.  
  29. has not been a one way road... strictly speaking it's not even
  30.  
  31. an evolution: you'll eventually find some very clever new tricks,
  32.  
  33. but most of the time you 'll unearth only various trite
  34.  
  35. repetitions of past (and well known) tricks. This is no wonder:
  36.  
  37. the REAL knowledge of the "commercial" programmers themselves
  38.  
  39. (the "protectionists") is often very limited indeed: they are
  40.  
  41. inclined to use the old methods (albeit somehow changed,
  42.  
  43. sometimes even improved) instead of conceiving new methods. This
  44.  
  45. typical "commercial" degeneration happens every time people act
  46.  
  47. for money instead of doing things for the sake of it or for
  48.  
  49. pleasure. This "commercial" trend is blindly encouraged by the
  50.  
  51. stupid, money-oriented society we are coerced to live in.
  52.  
  53.      So I'll begin the "hands on" part (-> starting from lesson
  54.  
  55. 3), using as examples, some "old" applications and some "old"
  56.  
  57. tricks. We'll be able to come later over to the newest protection
  58.  
  59. schemes in order to understand them, and you 'll learn how to
  60.  
  61. defeat this kind of junk too. I'll also explain WHERE you can
  62.  
  63. find a lot of programs to crack for next to no money at all, and
  64.  
  65. HOW 'grossomodo', you should proceed in your work.
  66.  
  67.      This tutorial is for people who are getting started with
  68.  
  69. cracking. Maybe you are just contemplating doing some cracking,
  70.  
  71. maybe you have tried it with mixed success. If you are here to
  72.  
  73. get aimed in the right direction, to get off to a good start with
  74.  
  75. the cracking tricks and procedures, then you have come for the
  76.  
  77. right reason. I can't promise you'll get what you want, but I'll
  78.  
  79. do my best. On the other hand, if you have already turned out
  80.  
  81. some working cracking code in assembler and already cracked many
  82.  
  83. different protection schemes, then this tutorial is likely to be
  84.  
  85. on the elementary side for you. (If you want to review a few
  86.  
  87. basics and have no where else pressing to go, then by all means
  88.  
  89. stay).
  90.  
  91.      In order to crack successfully you need four basic things:
  92.  
  93. *    A passing knowledge of assembler language (the more you
  94.  
  95.      know, the better and quicker you crack)
  96.  
  97. *    Some intuition
  98.  
  99. *    Some help from more experienced cracker
  100.  
  101. *    A non mercantile mind (more about this later)
  102.  
  103. The applications you'll use to learn with can be divided into:
  104.  
  105. 1    - Password crippled applications (the easiest to crack)
  106.  
  107. 2    - applications crippled on how many times, or how many
  108.  
  109.      days, you use them (fairly easy to crack)
  110.  
  111. 3    - applications crippled on which date you use them before
  112.  
  113.      (easy to crack)
  114.  
  115. 4    - applications that have some functions present but
  116.  
  117.      disabled (sometimes easy, sometimes difficult)
  118.  
  119. 5    - applications crippled on Disk access (protections schemes
  120.  
  121.      that are now defined as "obsolete") and applications
  122.  
  123. crippled on
  124.  
  125.      CD-ROM presence (more or less the same methods, but -
  126.  
  127.      somehow- not defined as "obsolete") (very easy to crack)
  128.  
  129. 6    - CRYPTOGRAFED ADDS ON (i.e. one of the previous protection
  130.  
  131.      schemes, but with some scrambled or self modifying code
  132.  
  133.      (XORring and SHRLing codes) (fairly easy to crack)
  134.  
  135. 7    - None of the above (sometimes difficult to crack)
  136.  
  137. WHERE TO GET THE STUFF
  138.  
  139.      The recent widespread appearance of "Demo"-CDROM on magazine
  140.  
  141. covers is a treasure for all crackers! A short time after their
  142.  
  143. release you 'll get all the copies that remain unsold for next
  144.  
  145. to free. The demos on CD-ROMs will permit you to gather quickly
  146.  
  147. a lot of applications -old and new- that have somehow been
  148.  
  149. crippled (at times with interesting schemes). Truly a wonderful
  150.  
  151. world of cracking possibilities! Gee! For next to no money you
  152.  
  153. can secure on one CDROM the whole of LOTUS applications (or
  154.  
  155. Microsoft or Wordperfect, or you name them) on "trial for 30
  156.  
  157. days" or "try it 20 times" editions. You'll really enjoy to crack
  158.  
  159. them, to use them for ever and ever and/or graciously donate them
  160.  
  161. on the Web to the poor lamers that have no money and no brain.
  162.  
  163.      GAMES are definitely not to be frowned upon! They are
  164.  
  165. very interesting from a cracker prospective coz they are often
  166.  
  167. "overprotected". With this I mean that they possess protection
  168.  
  169. schemes of a relatively HIGH level hidden inside files that are
  170.  
  171. relatively small. Now, see, it is much more easy, and simple, to
  172.  
  173. track down and eliminate protection schemes inside a single
  174.  
  175. 35.000 bytes long executable file than to locate them inside a
  176.  
  177. collection of many lengthy DLLs and overlaids that could have
  178.  
  179. swollen as long as 2.000.000 bytes each. The lazy bunch of
  180.  
  181. "modern" programmers relies systematically for protection schemes
  182.  
  183. on this "hide the sting in the wide desert" logic. As a matter
  184.  
  185. of fact they are no longer able to program in assembler: they
  186.  
  187. bank more and more on overbloated "fatty" atrocities like Visual
  188.  
  189. Basic, Delphy or Visual C++. (Don't worry... I'll nevertheless
  190.  
  191. teach you how to crack -and quickly- those huge applications
  192.  
  193. too).
  194.  
  195.      There is another reason for employing games instead of
  196.  
  197. applications as study material: often EXACTLY THE SAME protection
  198.  
  199. schemes that you find in a simple (and short) shareware game will
  200.  
  201. be used -without much improving- a little later in order to
  202.  
  203. "protect" some huge and extremely expensive graphic application.
  204.  
  205.      For this reason in my tutorial we'll often crack games
  206.  
  207. protection schemes, even if we'll later apply what we learn
  208.  
  209. mainly in order to crack the protection schemes of commercial
  210.  
  211. applications, or to crack the access protection routines to
  212.  
  213. remote servers, or BBS, or even ATM (cash dispensers).
  214.  
  215.      Here follows an example cracking session, that will show you
  216.  
  217. -I hope- the dos and donts of our art: let's crack together as
  218.  
  219. introductory example a time crippled application. We'll learn
  220.  
  221. later (-> LESSON 4) that all applications that are crippled on
  222.  
  223. time (i.e. "how many times" you use them or "how long" you use
  224.  
  225. them) rely on analogous protection schemes (albeit with a huge
  226.  
  227. palette of small variations):
  228.  
  229. 1-   they may have a counter which "clicks" every so often: FIND
  230.  
  231.      IT AND DISABLE IT!
  232.  
  233. 2-   they may fetch the time_clock interrupts in your machine:
  234.  
  235.      INTERCEPT THEM YOURSELF!
  236.  
  237. 3-   they may compare a random_seed with a variable: NOOP IT!
  238.  
  239. 4-   they may check randomly the date of your other, unrelated,
  240.  
  241.      files on the hard disk: find this verification routine and
  242.  
  243.      INVERT the JUMPS!
  244.  
  245. I wanted to start with a modern example of this "counter clicks"
  246.  
  247. protection type, just to give you a feeling for cracking, and I
  248.  
  249. have chosen a widely published demo: you should be able to find
  250.  
  251. it pretty easily. In order to show you some of the problems you
  252.  
  253. may encounter we'll crack this example "wrongly" (you'll learn
  254.  
  255. how to crack effectively in the "HANDS ON" lessons).
  256.  
  257.      EXAMPLE: ARCADE POOL, Demonstration version, PC Conversion
  258.  
  259. by East Point Software Ltd, (c) Team 17 Software Ltd 1994. This
  260.  
  261. demo has been published by many magazines on their CDRom covers
  262.  
  263. throughout 1995.
  264.  
  265.      What follows will be useful even if you do not have our
  266.  
  267. example; nevertheless you should get a copy of this widespread
  268.  
  269. demo in order to better grasp some of the following points.
  270.  
  271.      This nice demo of a billiard game is time-crippled. It is
  272.  
  273. crippled on how long you use it: i.e., you can only play 2
  274.  
  275. minutes, afterwards a "nag" reminder of where and how you can buy
  276.  
  277. the real version snaps: protectionist squalor at its best.
  278.  
  279.      So, how do you proceed? Where does the beginning begin?
  280.  
  281. Here is what you could (but not necessarily should) do:
  282.  
  283.      Get [Soft-ice] and load it in your config.sys. See the TOOLS
  284.  
  285. OF THE TRADE lesson (-> LESSON 2) about this debugger. Version
  286.  
  287. 2.6 of [Soft-Ice] has been cracked by MARQUIS DE SOIREE and can
  288.  
  289. be found on the Web for free.
  290.  
  291. -    vecs s (save all the vectors before loading the babe)
  292.  
  293. -    start [pooldemo.exe]
  294.  
  295. -    vecs c (vector compare, save a printing of all hooked
  296.  
  297.      vectors)
  298.  
  299. -    enter and leave Soft-ice a few times to understand what's
  300.  
  301.      going on and where in [pooldemo.exe] are we roaming around
  302.  
  303.      (you should always check MORE THAN ONCE your findings when
  304.  
  305.      you snoop around: nothing moves and confuses pointers in a
  306.  
  307.      more frenzied way than good old "inactive" DOS).
  308.  
  309. -    have a good look at the map of memory usage ("map")
  310.  
  311. -    now "snap_save" the main memory regions where
  312.  
  313.      [pooldemo.exe] dwells... snapping saves "photographs" of
  314.  
  315.      memory areas.
  316.  
  317. -    do not do anything, let just the seconds go by.
  318.  
  319. -    "snap_compare" every two or three seconds without moving
  320.  
  321.      anything at all on the game board (no mouse_clicking,
  322.  
  323.      NOTHING), so that the only changes are (hopefully) the
  324.  
  325.      changes caused by the time counters.
  326.  
  327. -    snap_compare twice in a second.
  328.  
  329. -    snap_compare at second 00:59 and at second 1:01.
  330.  
  331. -    snap_compare just before and just after the time limit and
  332.  
  333.      the snapping of the nag screen.
  334.  
  335. -    Now collect carefully your printed "snaps" data: write
  336.  
  337.      clearly on the various sheets the occurrences of the snaps.
  338.  
  339. -    now comes the graceful "zen-cracking" moment: Sit down with
  340.  
  341.      a dry Martini and Wodka (obviously only russian Wodka will
  342.  
  343.      do) and contemplate the printing of the various mutant
  344.  
  345.      locations. Feel, perceive, empathize! Look closely at the
  346.  
  347.      locations that have changed in the snap compares. Analyze,
  348.  
  349.      interpretate, evaluate.
  350.  
  351. -    Mmm! Hey! Something fishy is changing there, and there, and
  352.  
  353.      there! (you are lucky, few do actually change in this case:
  354.  
  355.      only two dozen)
  356.  
  357. -    breakpoint on execute at the location that you believe act
  358.  
  359.      as a "continuous" counter, i.e. the location that triggers
  360.  
  361.      the "a second went by" event when it zeroes.
  362.  
  363. -    Now set the occurrence counter of BPX in order to break at
  364.  
  365.      the moment where the location "refills" and restarts from
  366.  
  367.      the beginning (the equivalent of "one second" went by,
  368.  
  369.      let's start anew). Use the occurrence counter in order not
  370.  
  371.      to single-step through the program your life long!
  372.  
  373. -    IN THIS CASE you 'll quickly locate the refill at location
  374.  
  375.      3DD0. Here follows the "refill" line:
  376.  
  377.      xxxx:3DCC C706F1013C00   MOV  WORD PTR [01F1], 003C
  378.  
  379. The "3C" byte at xxxx:3DD0 represents a counter_byte... i.e. the
  380.  
  381. program "charges" 3C in this location and then DECs it step by
  382.  
  383. step to 3B, 3A, 39, 38 etc... till 0. When it reaches 0: bingo!
  384.  
  385. Sucker user has lost one second more of his precious two minutes.
  386.  
  387.      Now, you would get a first wizard level if you searched
  388.  
  389. further on for the exact point where you get the "nag screen" in
  390.  
  391. order to eliminate the whole witless protection, but you may
  392.  
  393. think you got it already and you remember anyway that the first
  394.  
  395. principle in cracking is the following: "once you can eliminate
  396.  
  397. the effects of a protection, do not look further!"
  398.  
  399.      Most of the time this is true: you do not always need to
  400.  
  401. eliminate a "whole" protection scheme (unless you are just
  402.  
  403. studying it for the joy of it). It's normally easier (and
  404.  
  405. quicker) to eliminate the "effects" of a given protection scheme.
  406.  
  407. Unfortunately this is not true in this case.
  408.  
  409.      Here you believe that you have already found the way: you
  410.  
  411. got the counter that charges the reverse clock that triggers the
  412.  
  413. particular protection scheme of [pooldemo.exe]. Now you may think
  414.  
  415. that if you could modify the refill_value... say changing "3C"
  416.  
  417. to "EE" (Yeah, the maximum would be FF... but it's always good
  418.  
  419. practice to avoid such extreme values when cracking) you should
  420.  
  421. get four times more playtime for your game... more than enough
  422.  
  423. in order to make the protection scheme useless.
  424.  
  425.      So you change location xxxx:3DD0 from "3C" to "EE". To work
  426.  
  427. on bytes you should use a good Hexeditor like PSEDIT (Parity
  428.  
  429. solutions, [Psedit.exe], brilliant shareware: see the "tool of
  430.  
  431. the trade" section) but you could also work with simpler
  432.  
  433. debuggers like [debug] or [symdeb] (-> see lesson 2). If you do,
  434.  
  435. remember to work on a "dead" copy of your crippled [*.exe] file,
  436.  
  437. i.e.:
  438.  
  439.      ren POOLDEMO.EXE POOLDEMO.DED
  440.  
  441.      symdeb POOLDEMO.DED
  442.  
  443.      -s (cs+0000):0 Lffff C7 06 F1 01 C3 <-  this string
  444.  
  445.                                              corresponds to the
  446.  
  447.                                              refill line).
  448.  
  449.      cs:3E85   <- symdeb gives you two locations as answer
  450.  
  451.      cs:3EEA
  452.  
  453.      -e cs:3E85+4 EE     <- refill changed from C3 to EE
  454.  
  455.      -w
  456.  
  457.      ren POOLDEMO.DED POOLDEMO.EXE
  458.  
  459. Now you run your tampered pooldemo. You think you cracked it, you
  460.  
  461. glee with satisfaction... but loo! Nothing at all has changed,
  462.  
  463. everything's as lame as before, you still have only 2 minutes
  464.  
  465. playtime. How disappointing: how comez it didn't work?
  466.  
  467.      Well, for a start you have not been attentive enough! The
  468.  
  469. search in debug gave you TWO locations, you moron, and not just
  470.  
  471. the one you just tampered with. Check and you 'll see that the
  472.  
  473. second location (cs:3EEA) is a MIRROR/CONTROL location (more on
  474.  
  475. this later). Some times there exist "double" locations... coz at
  476.  
  477. times it's quicker to use a double routine than to use a
  478.  
  479. branching if or switch structure... some times the second
  480.  
  481. locations do mirror the first ones and correct them on the fly
  482.  
  483. if need be.
  484.  
  485.      So you need to modify this too... you act as said above but
  486.  
  487. this time you enter in debug a
  488.  
  489.      -e cs:3EEA+4 EE
  490.  
  491. before writing back the dead file and then renaming it to exe and
  492.  
  493. then running it... and loo! Hoow sloow! THERE YOU ARE! Your
  494.  
  495. crippled POOLDEMO.EXE is now (sort of) unprotected: You think
  496.  
  497. that you can now play the stupid game up to 12 minutes real time,
  498.  
  499. even if the protection scheme (and the counter) "believes" that
  500.  
  501. it is playing only two minutes.
  502.  
  503.      So you begin to play, and the seconds look veeery sloow, and
  504.  
  505. everything seems OK, but -alas- NO! At screen second 28 you get
  506.  
  507. the irritating "two minutes are over" nag screen! Obviously you
  508.  
  509. were dead wrong: the program "knows" the time directly from the
  510.  
  511. timer... you only modified the stupid counter ON THE SCREEN.
  512.  
  513.      So it's back to cracking, and now you are angry, and forget
  514.  
  515. the quiet ways of the zen-analyze and begin the heavy cracking
  516.  
  517. you should reserve -if ever- for really complicated schemes. You
  518.  
  519. now start to check the hooked vectors (you did your routinely
  520.  
  521. VECS_save before loading pooldemo in [Soft-ice] and your
  522.  
  523. VECS_compare afterwards) and you see some findings that you
  524.  
  525. believe interesting:
  526.  
  527.           vecs c
  528.  
  529.           08   1EFD:84C6 0CD1:17AC <- the clock
  530.  
  531.           09   1EFD:85EC 136A:069C <- the keyboard
  532.  
  533.           22   0BCE:02B1 0BCE:017E <- the terminate
  534.  
  535.      That's more like it -you think. Smack at the beginning: the
  536.  
  537. first hooked vector does it! It's good old interrupt_08: the
  538.  
  539. timer_clicker!
  540.  
  541.      Some basics for those of you that do not know anything:
  542.  
  543. INT_08 controls indirectly the INT_1C timer interrupt. The 8253
  544.  
  545. clock chip generates an IRQ_0 hardware interrupt at a rate of
  546.  
  547. 18.2 interrupts per second. This gives control to the ISR
  548.  
  549. (Interrupt Service Routine) that the INT_08 points to... and this
  550.  
  551. should be at 0CD1:17AC, but has been hooked here, by pooldemo,
  552.  
  553. to 1EFD:84C6.
  554.  
  555.      One of the actions taken by the INT_08 ISR within the BIOS
  556.  
  557. is to issue a software interrupt call to INT_1C, just in case any
  558.  
  559. software modules within the system have established an intercept.
  560.  
  561. If no intercepts have been established, the default contents of
  562.  
  563. the INT_1C vector point to an iret instruction within the BIOS,
  564.  
  565. so that a null action results.
  566.  
  567.      Normally a protectionist would intercept INT_1C, coz at
  568.  
  569. every ISR from INT_08 the CPU would fetch the contents of the
  570.  
  571. corresponding interrupt vector and make an interrupt style call
  572.  
  573. to the code at that address (which should contain the iret at
  574.  
  575. address F000:9876 but can contain any trick they could think of).
  576.  
  577.      So -you think- the protectionist hooked here INT_08 directly
  578.  
  579. (a pretty infrequently used protection scheme by the way): What
  580.  
  581. now?
  582.  
  583.      A rather drastic measure would be, in such circumstances,
  584.  
  585. to
  586.  
  587. disable the IRQ_0 level timer interrupt, which is controlled by
  588.  
  589. bit 0 of the mask register, at address I/O 0021h. When bit 0
  590.  
  591. within the mask register is set to 1, no further interrupts will
  592.  
  593. be recognized for this IRQ level. This unfortunately won't work
  594.  
  595. here, but it's an interesting technique per se, so you better
  596.  
  597. learn it anyway, just in case you should need it elsewhere:
  598.  
  599. --- Trick to disable the timer ("IRQ_0 masking" by +ORC) ---
  600.  
  601. *    prompt $t and hit ENTER a few times, see how the dos_clock
  602.  
  603.      is merrily ticking along?
  604.  
  605. *    enter DEBUG.COM
  606.  
  607. *    Assemble using the command 'a'
  608.  
  609. - a
  610.  
  611. in al,21
  612.  
  613. or al,1
  614.  
  615. out 21,al
  616.  
  617. ret
  618.  
  619. RETURN
  620.  
  621. RETURN    <- twice to exit immediate assembler
  622.  
  623. - g 100   <- to run the tiny program.
  624.  
  625. - q       <- to quit debug.
  626.  
  627. prompt $t is still on: hit ENTER a few times:
  628.  
  629. whoa! The clock has stopped advancing!
  630.  
  631.      Compliments: you loaded the current mask register's contents
  632.  
  633. into AL, you set the mask bit in the bit 0 position (which
  634.  
  635. corresponds to IRQ_0) at then updated the value back to the mask
  636.  
  637. register.
  638.  
  639. When you are ready to activate IRQ_0 events again, reenter DEBUG,
  640.  
  641. run the following and then reset the clock you stopped with DOS
  642.  
  643. TIME command:
  644.  
  645. - a
  646.  
  647. in al,21
  648.  
  649. and al,fe
  650.  
  651. out 21,al
  652.  
  653. ret
  654.  
  655. RETURN twice
  656.  
  657. - g 100
  658.  
  659. - q
  660.  
  661. A word of caution: with the timer click disabled some processes
  662.  
  663. will not operate correctly: once you access the diskette drive,
  664.  
  665. the motor will continue to run indefinitely afterwards, etcetera.
  666.  
  667. -------------------------------------------------------
  668.  
  669.      Unfortunately the above technique cannot work with our
  670.  
  671. [pooldemo.exe], where you now are looking closely to the INT_08
  672.  
  673. hook you found, believing that it hides the protection scheme:
  674.  
  675. herein you find immediately the EoI (End_of_interrupt: MOV
  676.  
  677. AL,20h... OUT 20h,AL). Both controllers have a second port
  678.  
  679. address at 20h (or 0a0h), from which the instructions are given.
  680.  
  681. The most important is the EoI command (20h). This instruction
  682.  
  683. indicates the end of the interrupt handler and frees up the
  684.  
  685. corresponding controller for the next interrupt. If somebody
  686.  
  687. writes a new custom interrupt handler (as many protectionists
  688.  
  689. do), it's up to him to see to it that at the end of the handler
  690.  
  691. the EoI command (20h) is written to either port 20h or port 0a0h.
  692.  
  693.      After the EoI follow the usual pushes, then some CALLS then
  694.  
  695. a call that issues some OUT 40,AL that look like timer refreshing
  696.  
  697. (OUT transfers data to an output port and ports 40-42 correspond
  698.  
  699. to the Timer/counter). Some do_maintenance follows, then a double
  700.  
  701. CALL, one more conditional CALL and then a "mysterious" call FAR
  702.  
  703. CS:[AA91] on which depends a byte PTR[970C] that decides another
  704.  
  705. final CALL... then the routine pops all registers and irets away.
  706.  
  707.      Ah! You say, and begin disassembling, reverse engineering
  708.  
  709. and looking inside each suspect call (the quicker method in
  710.  
  711. these cases is to breakpoint calls on entrance and see if you
  712.  
  713. find the one that's only called at the awakening of the time
  714.  
  715. limit protection).
  716.  
  717.      You work, and work, and work... and eventually find nothing
  718.  
  719. at all, coz the protection of this program is NOT HERE!
  720.  
  721.      Back to the zen-analyze of the snap printings... we forsake
  722.  
  723. it too soon, as you will see.
  724.  
  725.      If you watch with more attention the compare locations for
  726.  
  727. the range DS:0 DS:FFFF you 'll notice that one of them changes
  728.  
  729. relatively slowly from 0 to 1 to 2 to 3 and so on... the
  730.  
  731. precedent location changes very quickly, and runs the complete
  732.  
  733. cycle 0...FF. That's a counter, at locations DS:0009 and DS:000A!
  734.  
  735. How long will it tick along? Well, we saw above that the "charge"
  736.  
  737. every second is 3C, so it will be x3C*x78=x1C20, coz x78 is 120
  738.  
  739. seconds, i.e. the two minutes time limit.
  740.  
  741.      Now search this 1C20 value around inside the code
  742.  
  743. (protections are most of the time at the beginning of the
  744.  
  745. CS:offset section), and you 'll find quickly what follows:
  746.  
  747. The protection in [pooldemo.exe] is at code_locations
  748.  
  749. CS:0A8A   813E20A7201C   CMP  WORD PTR [A720], 1C20
  750.  
  751.                          compare location A720 with limit 1C20
  752.  
  753. CS:0A90   7C07           JL   okay_play_a_little_more
  754.  
  755. CS:0A92   E834FD         CALL beggar_off_time_is_up
  756.  
  757.      BINGO!: FOUND!
  758.  
  759. Now let's quickly crack it:
  760.  
  761. ------------------------------------------------
  762.  
  763. CRACKING POOLDEMO.EXE (by +ORC, January 1996)
  764.  
  765. ren pooldemo.exe pooldemo.ded
  766.  
  767. symdeb pooldemo.ded
  768.  
  769. -    s cs:0 Lffff 81 3E 20 A7 20 1C
  770.  
  771. xxxx:yyyy           <- this is the answer of the debugger
  772.  
  773. -    e xxxx:yyyy+5 4C  <- this time limit is much better
  774.  
  775. -    w
  776.  
  777. -    q
  778.  
  779. ren pooldemo.ded pooldemo.exe
  780.  
  781. -------------------------------------------------
  782.  
  783.      We have done here a "weak" crack: we limited ourselves to
  784.  
  785. accept a (better) time limit, changing it from 1C20 to 4C20 (4
  786.  
  787. minutes instead of two). We could obviously have done a more
  788.  
  789. radical crack if we had changed the JL (jump lower) instruction
  790.  
  791. in a JMP (jump anyway) instruction. In this case it would have
  792.  
  793. worked, but for reasons that will be explained in lesson 4, you
  794.  
  795. should choose a rather delicate approach in cracking when you
  796.  
  797. deal with time-limit protection schemes.
  798.  
  799.      As you have seen, in this artificial cracking session we
  800.  
  801. found the protection scheme after a little snooping around. But,
  802.  
  803. as you will see in the hands on part, there are always MANY ways
  804.  
  805. to crack a single protection scheme. You could -for instance-
  806.  
  807. have found this protection the other way round: set a trace on
  808.  
  809. memory range for the program, restricting the trace to the first
  810.  
  811. part of it (say CS:0 to CS:1000, if you do not fetch anything you
  812.  
  813. can always try the other blocks). Breakpoint at the nag screen,
  814.  
  815. have a look at the last 300-400 backtraced instructions, if you
  816.  
  817. did not move anything, everything will follow a repetitive
  818.  
  819. pattern, until the protection snaps on:
  820.  
  821.        ...
  822.  
  823.        JL 0A99
  824.  
  825.        CMP BYTE PTR [A72A],01
  826.  
  827.        ...
  828.  
  829.        JL 0A99
  830.  
  831.        CMP BYTE PTR [A72A],01
  832.  
  833.        ...
  834.  
  835.        for ages and ages and then...
  836.  
  837.        ...
  838.  
  839.        JL 0A99
  840.  
  841. E834FD CALL 0759           <- BINGO! (CALL beggar_off_time_is_up)
  842.  
  843. ... there it is, found the other way round. (But this apparently
  844.  
  845. better method is unfortunately very unstable: it depends on your
  846.  
  847. timing of the breaking in and on the distance between protection
  848.  
  849. and nag screen, therefore the somehow more complicated, but more
  850.  
  851. sure previous one should be favoured).
  852.  
  853.      The reason why "minimal" approaches in cracking are often
  854.  
  855. more successful than heavy vector_cracking, is that the programs
  856.  
  857. are hardly ever "overprotected", and therefore the protections
  858.  
  859. are seldom difficult to find (and those that are really worth
  860.  
  861. cracking for study reasons).
  862.  
  863.      Sometime you don't even need to crack anything at all! Some
  864.  
  865. applications are fully functional -per se-, but have been
  866.  
  867. crippled in a hurry in order to release them as demos. The
  868.  
  869. commercial programmers want only money, do not even try to
  870.  
  871. understand our zen ways, and do not care at all for a well done
  872.  
  873. job. That means, among other things, that the hard disk of the
  874.  
  875. user will be cluttered with files that the main program module
  876.  
  877. never calls. A typical example of this sloppy method is the demo
  878.  
  879. of [Panzer General] from SSI that appeared in the summer '95.
  880.  
  881. This was in reality no less than the complete beta version of the
  882.  
  883. game: you just had to substitute to one of the two "allowed"
  884.  
  885. scenarios one of the 20 or more scenarios of the beta version in
  886.  
  887. order to play them freely... you didn't ever need to crack!
  888.  
  889.      The pooldemo crack example above should not discourage you
  890.  
  891. from cracking intuitively. Be careful! Perform a thoroughly
  892.  
  893. zen_analyze before attempting deeper methods: do remember that
  894.  
  895. you want to crack the protection scheme SOMEHOW, and not
  896.  
  897. necessarily following the same line of thought that the
  898.  
  899. programmer eventually WANTED YOU TO CRACK IT with.
  900.  
  901. Well, that's it for this lesson, reader. Not all lessons of my
  902.  
  903. tutorial are on the Web.
  904.  
  905.      You 'll obtain the missing lessons IF AND ONLY IF you mail
  906.  
  907. me back (via anon.penet.fi) with some tricks of the trade I may
  908.  
  909. not know that YOU discovered. Mostly I'll actually know them
  910.  
  911. already, but if they are really new you'll be given full credit,
  912.  
  913. and even if they are not, should I judge that you "rediscovered"
  914.  
  915. them with your work, or that you actually did good work on them,
  916.  
  917. I'll send you the remaining lessons nevertheless. Your
  918.  
  919. suggestions and critics on the whole crap I wrote are also
  920.  
  921. welcomed.
  922.  
  923.                                 E-mail +ORC
  924.  
  925.                         +ORC an526164@anon.penet.fi
  926.